\fIProcedures for user\(hyto\(hyuser signalling associated with\fR
\fIcircuit\(hyswitched calls\fR
.sp 1P
.RT
.sp 1P
.LP
7.1.1
\fIGeneral\fR
.sp 9p
.RT
.PP
The user\(hyto\(hyuser signalling supplementary service(s) provides a
means of communication between two users by using as a basis the layer\ 3
protocol defined in \(sc\ 5. User\(hyto\(hyuser signalling is used to exchange
information between two users to provide the services described in the
I.257A Recommendations. The exchange of user\(hyto\(hyuser signalling is
limited by flow
control procedures provided by the network or the user. The exchange of
user\(hyto\(hyuser information is not a network acknowledgement service. Any
acknowledgement procedure shall be controlled at a higher layer between users.
.PP
Three user\(hyto\(hyuser signalling services associated with
circuit\(hyswitched calls that may be provided by the network to users
are:
.RT
.LP
i)
Service 1:
.LP
user\(hyto\(hyuser signalling exchanged during the set\(hyup and
clearing phases of a call, within Q.931 call control
messages.
.LP
ii)
Service 2:
.LP
user\(hyto\(hyuser signalling exchanged during call establishment,
between the ALERTING and CONNECT messages, within USER
INFORMATION messages.
.LP
iii)
Service 3:
.LP
user\(hyto\(hyuser signalling exchanged while a call is in the
Active state, within USER INFORMATION messages.
.PP
All three services may be used separately or in any combination in association
with a single call. As an option, at call set\(hyup, users may be able
to specify that the requested user\(hyto\(hyuser signalling service(s)
is (are)
required for the call, i.e.,\ the call should not be completed if user\(hyto\(hyuser
information cannot be passed.
.sp 1P
.LP
7.1.2
\fIExplicit invocation procedures for services 1, 2 and 3\fR
.sp 9p
.RT
.PP
Services 1, 2 and 3 listed above may be provided on a per call
basis following an explicit request from a user. The standard explicit
invocation procedure makes use of the Facility information element defined
in \(sc\ 4.
.PP
In addition, or alternatively, some networks may support explicit
invocation procedures making use of:
.RT
.LP
\(em
keypad facility information element; or
.LP
\(em
feature activation information element.
.bp
.PP
The exact operation of stimulus invocation procedures are network dependent
but must follow the rules defined in \(sc\ 8 of this Recommendation. More
detailed protocol aspects can also be found in \(sc\ 4 (for the keypad
protocol
invocation) and in \(sc\ 5 (for the feature management protocol invocation)
of Recommendation\ Q.932.
.PP
When a network supports more than one invocation procedure, the
following principles shall be followed:
.RT
.LP
\(em
for invocations using the Keypad facility information
element, the network will convey the remote user's response
using a Signal, a Display, or a Feature indication information
element;
.LP
\(em
for invocations using the Feature activation information
element, the network will convey the remote user's response
using a Feature information element;
.LP
\(em
for invocations using the Facility information element,
the network will convey the remote user's response using
a Facility information element.
.PP
In the network\(hyto\(hyuser direction, explicit service 1 and service\
2 requests may be indicated using the Facility information element.
.PP
In the network\(hyto\(hyuser direction, service 3 request may be indicated
using:
.RT
.LP
i)
signal information element (see Note);
.LP
ii)
display information element (see Note);
.LP
iii)
feature indication information element (see Note); or
.LP
iv)
facility information element.
.PP
For indications using the Facility information element, the user will respond
with a Facility information element. No response is needed when
any of the first three information elements are used.
.PP
\fINote\fR \ \(em\ These may be used only when the network has knowledge that
the user receiving the notification has subscribed to the service. In this
case, the network will generate the service confirmation to the originating
user (i.e.,\ the user requesting the service) on behalf of the user who
did not originate the service request. For service\ 3, invoked during the
active state of a call, the message use is symmetric across the user\(hynetwork
interface;
i.e.,\ the FACILITY message is returned in response to a FACILITY message.
.RT
.sp 2P
.LP
7.1.3
\fIUser\(hyto\(hyuser signalling service 1\fR
.sp 1P
.RT
.sp 1P
.LP
7.1.3.1
\fIGeneral characteristics\fR
.sp 9p
.RT
.PP
Service 1 allows the users to communicate by means of user\(hyto\(hyuser
signalling by transferring user\(hyto\(hyuser information within Recommendation\
Q.931 call control messages during call establishment and clearing phases.
.RT
.sp 1P
.LP
7.1.3.2
\fIUser\(hyto\(hyuser signalling \(em implicit service request (preferred,\fR
\fIi.e. \(em not required)\fR
.sp 9p
.RT
.PP
Service 1 may be implicitly requested by including a User\(hyuser
information element of variable length as specified in \(sc\ 4.5.29 in
the SETUP
message transferred across the user\(hynetwork interface at the calling side as
described in \(sc\ 5.1.1. This information element is transported by the
network
and delivered unchanged in the User\(hyuser information element included in the
SETUP message transferred across the user\(hynetwork interface at the called
side as described in \(sc\ 5.2.1. For invocation purposes, this information
element must be at least three octets long as defined in \(sc\ 4.5.29.
.PP
In the case where contention by users for the incoming call is not
allowed (e.g.,\ when the SETUP message containing an implicit service invocation
is delivered using a point\(hyto\(hypoint link at the data link layer or
when the
network, despite using broadcast capability at layer\ 2, knows based on the
first response received from the user that no contention takes place), a
User\(hyuser information element may be included in the ALERTING and/or CONNECT
messages transferred across the user\(hynetwork interface at the called side as
described in \(sc\ 5.2.5. The content of this information element is transported
by the network and delivered in the User\(hyuser information element included
in the corresponding message(s) transferred across the user\(hynetwork
interface at the calling side as described in \(sc\(sc\ 5.1.7 and\ 5.1.8.
.PP
In the case where users are allowed to contend for an incoming call
(e.g., when the SETUP message containing an implicit service
invocation is delivered using the broadcast capability at the data link
layer and the network is unable to determine based upon the first response
received from the user that there is no contention), the User\(hyuser information
element may be included in the CONNECT message transferred at the called
side. The
content of the User\(hyuser information element delivered to the calling user
shall be that received from the selected terminal as described in \(sc\ 5.2.8.
.bp
.PP
\fINote\ 1\fR \ \(em\ The user may not be able to interpret incoming user\(hyto\(hyuser
information. In such situations, the user should discard this information
without disrupting normal call handling. No specific signalling is provided
by the network to accommodate this situation.
.PP
\fINote\ 2\fR \ \(em\ In accordance with Recommendation X.213, the called user
may perform compatibility checking using the User\(hyuser information element
contents (see Annex\ B).
.RT
.sp 1P
.LP
7.1.3.3
\fIUser\(hyto\(hyuser signalling in the call establishment phase\fR
\fI\(em\ explicit service request (preferred or required)\fR
.sp 9p
.RT
.PP
Procedures for call establishment are as described in \(sc\(sc\ 5.1 and
5.2 with the following modifications:
.PP
On call request, the SETUP message sent by the calling user shall
contain a service\ 1 request. The SETUP message sent by the network at the
called side shall also contain an explicit service\ 1 request.
.PP
In the case where contention by users for the incoming call is not
allowed (e.g., when the SETUP is delivered using the point\(hyto\(hypoint
data link layer or when the SETUP is delivered using the broadcast capability
at the
data link layer and the network is able to determine that no contention is
occurring), and the called user can support the transfer of User\(hyuser
information elements during the call, a service\ 1 acceptance shall be
included in the ALERTING message.
.PP
This explicit service 1 acceptance will be forwarded by the network to
the calling user in the ALERTING message.
.PP
A User\(hyuser information element may be included in the ALERTING
message and/or CONNECT message transferred across the user\(hynetwork interface
at the called side as described in \(sc\ 5.2.5.
.PP
In accordance with Recommendation X.213, the called user may perform compatibility
checking using the User\(hyuser information element contents (see
Annex\ B).
.PP
\fINote\fR \ \(em\ The use of the explicit service 1 request procedures
in the case where contention by the users for the incoming call is allowed
(e.g.\ the SETUP message is delivered using the broadcast capability at
the data link
layers and the network is unable to determine that there is no contention)
is for further study.
.RT
.sp 1P
.LP
7.1.3.4
\fIInterworking\fR
.sp 9p
.RT
.PP
In the case of interworking with a non\(hyISDN network, the return of a
PROGRESS or an ALERTING message with the Progress indicator information
element indicating No. 1, \fIcall is not end\(hyto\(hyend ISDN; further
call progress\fR \fIinformation may be available in\(hyband\fR , to the
calling user shall serve as
indication that, in particular, the delivery of User\(hyuser information
elements in call control messages cannot be guaranteed.
.RT
.sp 1P
.LP
7.1.3.5
\fIRejection of implicit service requests\fR
.sp 9p
.RT
.PP
Networks that cannot provide the service requested will not return a rejection
indication.
.RT
.sp 1P
.LP
7.1.3.6
\fIRejection of explicit service requests\fR
.sp 9p
.RT
.PP
If the called user or network does not understand the service 1
request, then the ALERTING message returned to the calling party shall not
include either a service\ 1 acceptance or rejection. This type of response
will be taken as an implicit rejection of service\ 1.
.PP
If the network or called user cannot support service 1, and it was
requested as preferred, a service\ 1 rejection is included in the ALERTING
message.
.PP
If the service 1 request indicated as required and the called user or network
cannot support it, a RELEASE COMPLETE is sent with cause No.\ 50,
\fIrequested facility not subscribed\fR , or cause No.\ 69, \fIrequested
facility not\fR \fIimplemented\fR , and a service\ 1 rejection.
.PP
If the called user does not include a service 1 acceptance or
rejection in the ALERTING message, the network shall return an explicit
rejection in the ALERTING message sent to the calling user.
.bp
.RT
.sp 1P
.LP
7.1.3.7
\fIUser\(hyto\(hyuser signalling in the call clearing phase\fR
.sp 9p
.RT
.PP
A User\(hyuser information element may be included in the first
message used to initiate the normal call clearing phase (see \(sc\(sc\ 5.3.3
and\ 5.3.4).
.PP
The information contained in such an information element is
transferred to the remote user in the first clearing message (see \(sc\(sc\
5.3.3
and\ 5.3.4). Such a transfer is only performed if the information is received
at the local exchange of the remote user before sending a clearing message
to that user, otherwise, the information is discarded without sending any
notification.
.PP
In addition, when a SETUP message has been delivered using the
broadcast capability at the data link layer, and the network is unable to
determine from the first response received from the user that there is no
contention, only the following user\(hyto\(hyuser information transfer is
allowed:
.RT
.LP
i)
in the network to called user direction:
.LP
in the case of premature clearing by the calling user,
user\(hyto\(hyuser information is sent in the first clearing message
to each called user that has already responded to the
incoming SETUP message;
.LP
ii)
in the called user\(hynetwork direction:
.LP
the user\(hyto\(hyuser information will only be accepted from a
terminal which is selected.
.PP
If multiple clearing messages are received, the network may, as a network
option, retain the User\(hyuser information element along with the cause
retained according to \(sc\ 5.2.5.4. In the event that this cause is returned
to to calling user, the associated User\(hyuser information element shall
also be
returned. If there are multiple clearing messages containing causes of equal
priority and User\(hyuser information elements, the User\(hyuser information
element contained in the first clearing message will be sent to the calling
user. If
any of the clearing messages with the highest priority causes do not contain
User\(hyuser information elements and other clearing messages with causes
of lower priority do contain User\(hyuser information elements, no User\(hyuser
information
element shall be sent back to the calling user.
.PP
In the case where contention by users for the incoming call is not
allowed (e.g.,\ when the SETUP message is delivered using the point\(hyto\(hypoint
data link layer or the network knows that a user responding to a SETUP sent
using the broadcast capability at the data link layer is not contending
for the call) a User\(hyuser information element may be included in the
first clearing
message sent by the called user prior to entering the Active state.
.PP
In the case where contention by users for the incoming call is not
allowed, if the called user rejects the call with a RELEASE COMPLETE message
containing user\(hyuser information, the network shall deliver the user\(hyuser
information in the DISCONNECT message sent to the calling user. However,
if the network is providing in\(hyband information to the calling user,
and chooses not to initiate clearing procedures at that time, the network
may deliver the
user\(hyuser information in a PROGRESS message sent to the calling user.
.PP
If the network is providing in\(hyband information to the calling user,
in conjunction with call clearing, the network shall include the User\(hyuser
information element in the DISCONNECT message sent to the calling user.
.PP
\fINote\fR \ \(em\ It is intended that this capability may be used to provide
the clearing data transfer described in Recommendation\ X.213.
.RT
.sp 1P
.LP
7.1.3.8
\fIUnexpected user\(hyuser information in call control messages\fR
.sp 9p
.RT
.PP
The network shall discard the User\(hyuser information element if it is
received from either user in an ALERTING, CONNECT, DISCONNECT, RELEASE
or
RELEASE COMPLETE message but a request for user\(hyuser signalling was not
indicated (either explicitly or implicitly) in the SETUP message delivered
to the user. If this occurs, the network shall take action on the remaining
contents of the message received from the user and shall send a STATUS
message to the user containing cause No.\ 43, \fIaccess information discarded\fR
.
.RT
.sp 2P
.LP
7.1.4
\fIUser\(hyto\(hyuser signalling service 2\fR
.sp 1P
.RT
.sp 1P
.LP
7.1.4.1
\fIGeneral characteristics\fR
.sp 9p
.RT
.PP
Service 2 allows the users to communicate by means of user\(hyto\(hyuser
signalling by transferring two USER INFORMATION messages in each direction
during the call establishment phase. This service allows either an implicit
or explicit rejection (see \(sc\ 7.1.4.3).
.PP
Service 2 is only applicable when a SETUP message has been delivered using
the point\(hyto\(hypoint data link layer at the user\(hynetwork interface
at the called side.
.bp
.RT
.sp 1P
.LP
7.1.4.2
\fICall establishment\fR
.sp 9p
.RT
.PP
Procedures for call establishment are as described in \(sc\(sc\ 5.1 and
5.2 with the following modifications.
.PP
On call request, the SETUP message sent by the calling user will
contain a service\ 2 request. The SETUP message sent by the network at the
called side will also contain an explicit service\ 2 request.
.PP
If the called user can support USER INFORMATION messages during call establishment,
a service\ 2 acceptance shall be included in the ALERTING message sent
to the network. This explicit acceptance indication shall be forwarded
in the ALERTING message sent by the network to the calling user.
.RT
.sp 1P
.LP
7.1.4.3
\fIService rejection\fR
.sp 9p
.RT
.PP
If the called user or network does not understand the service\ 2
request, then the ALERTING message returned to the calling user will not
include either a service\ 2 acceptance or rejection. This type of response
shall be taken as an implicit rejection of service\ 2. Alternatively, if
the network or called user cannot support USER INFORMATION messages during
call
establishment, and the request is indicated as preferred, a service\ 2
rejection is included in the ALERTING message.
.PP
If the service 2 request indicated is required, and the called user or
network cannot support or provide the service, a RELEASE COMPLETE is sent
with cause No.\ 50, \fIrequested facility not subscribed\fR , or cause
No.\ 69, \fIrequested\fR \fIfacility not implemented\fR , and a service\
2 rejection.
.PP
If the called user does not include a service 2 acceptance or
rejection in the ALERTING message, the network shall return an explicit
rejection in the ALERTING message sent to the calling user.
.PP
In the case of interworking with a non\(hyISDN network, a PROGRESS or
ALERTING message with the progress indicator information element indicating
No.\ 1, \fIcall is not end\(hyto\(hyend ISDN; further call progress information
may be\fR \fIavailable in\(hyband\fR , is sent to the calling user to indicate
that the full
service cannot be guaranteed.
.RT
.sp 1P
.LP
7.1.4.4
\fITransfer of USER INFORMATION messages\fR
.sp 9p
.RT
.PP
Once an ALERTING message has been received, both the involved users can
transfer information between themselves by transferring USER INFORMATION
messages across the user\(hynetwork interface. The network provides for the
transfer of such messages from the calling to the called side and vice versa.
.PP
The USER INFORMATION message includes the Call reference, the Protocol
discriminator, and the User\(hyuser information elements as defined in
\(sc\ 3.1.23. The More data information element may also be included by
the source user to
indicate to the remote user that another USER INFORMATION message will
follow, containing information belonging to the same block. The use of
More data
information element is not supervised by the network.
.PP
If the user\(hyto\(hyuser signalling facility is provided, no more than
two USER INFORMATION messages may be transferred in each direction after
the
ALERTING message and before the CONNECT message.
.PP
Sending or receiving of USER INFORMATION messages does not change the state
of the call.
.RT
.sp 2P
.LP
7.1.5
\fIUser\(hyto\(hyuser signalling service 3\fR
.sp 1P
.RT
.sp 1P
.LP
7.1.5.1
\fIGeneral\fR
.sp 9p
.RT
.PP
Service 3 allows the users to communicate by means of transferring USER
INFORMATION messages during the Active state of a call. This service
allows either an implicit or explicit rejection (see \(sc\ 7.1.5.3). This
service may be requested during call establishment or during the Active
state of the
call.
.RT
.sp 1P
.LP
7.1.5.2
\fIService request during call establishment\fR
.sp 9p
.RT
.PP
Procedures for call establishment are as described in \(sc\(sc 5.1 and
5.2 with the following modifications:
.RT
.LP
a)
On call request, the SETUP message sent by the calling user
will contain a service\ 3 request. The SETUP sent by the network
at the called side will also contain a service\ 3 request.
.LP
b)
If the called user can support USER INFORMATION message
transfer during the Active state, a service\ 3 acceptance shall
be included in the CONNECT message.
.bp
.sp 1P
.LP
7.1.5.3
\fIRejection of service requested during call establishment\fR
.sp 9p
.RT
.PP
If the called user or network does not understand the service 3
request, then the CONNECT message returned to the calling user shall not
include either a service\ 3 acceptance or rejection. This type of response
will be taken as an implicit rejection of service\ 3. Alternatively, if
the network or called user cannot support USER INFORMATION messages during
the Active
state, and the request is indicated as preferred, a service\ 3 rejection is
included in the CONNECT message. If the service\ 3 request indicated required,
and the called user or network cannot support or provide the service, a
RELEASE COMPLETE is sent with cause No.\ 50, \fIrequested facility not
subscribed\fR , or
cause No.\ 69, \fIrequested facility not implemented\fR , and a service\
3 rejection.
.PP
If the called user does not include a service 3 acceptance or
rejection in the CONNECT message, the network shall return a service\ 3
rejection in the CONNECT message sent to the calling user.
.PP
When interworking with a non\(hyISDN network occurs, a PROGRESS or an
ALERTING message with the Progress indicator information element indicating
No.\ 1, \fIcall is not end\(hyto\(hyend ISDN; further call progress information
may be\fR \fIavailable in\(hyband\fR , is sent to the calling user to indicate
that the service cannot be guaranteed.
.RT
.sp 1P
.LP
7.1.5.4
\fIService request after call establishment\fR
.sp 9p
.RT
.PP
During the Active state of a call, a user may request service 3
preferred only. A FACILITY message indicating a service\ 3 request is sent
from the requesting user to the network. The network shall indicate the
service\ 3
request to the user that did not request service\ 3 in the FACILITY message.
.PP
If the user that did not request service 3 can support the transfer of
USER INFORMATION messages during the Active state, a service\ 3 acceptance
is
returned in the FACILITY message. This explicit acceptance indication shall
be conveyed back to the requesting user in a FACILITY message.
.RT
.sp 1P
.LP
7.1.5.5
\fIRejection of service request after call establishment\fR
.sp 9p
.RT
.PP
If the user that did not request service 3 or network does not
understand the service\ 3 request, then no message is returned. This response
shall be taken as an implicit rejection of the service request. Alternatively,
if the requested user or network cannot support or provide the service
requested, a service\ 3 rejection shall be returned in the FACILITY message.
.PP
If the requested user does not respond to the service 3 request, the network
shall return a service\ 3 rejection to the calling user.
.RT
.sp 1P
.LP
7.1.5.6
\fITransfer of USER INFORMATION messages\fR
.sp 9p
.RT
.PP
Once the call is established, both users can transfer information between
themselves by transporting USER INFORMATION messages across the
user\(hynetwork interface. The network provides for the transfer of such
messages from the calling to the called side and vice versa.
.PP
The USER INFORMATION message includes the Call reference, the Protocol
discriminator, and the User\(hyuser information elements. The More data
information element may also be included by the source user to indicate
to the remote user that another USER INFORMATION message will follow, containing
information belonging to the same block. The use of the More data information
element is not supervised by the network.
.RT
.sp 1P
.LP
7.1.5.7
\fICongestion control of USER INFORMATION messages\fR
.sp 9p
.RT
.PP
The network or user will flow\(hycontrol, when needed, the transfer of
USER INFORMATION messages from a user or network by means of a CONGESTION
CONTROL message containing a congestion level information element. Two
indications of congestion level are specified: \fIreceive not ready\fR and
\fIreceive ready\fR . On receipt of the former, the user or network should
suspend sending USER INFORMATION messages; on receipt of the latter, sending
may
recommence. After having sent a receive not ready indication, the network or
user shall discard USER INFORMATION messages which are subsequently received.
The network or user will send a CONGESTION CONTROL message with a receive
not ready indication whenever a USER INFORMATION message is locally discarded,
if it is possible. The CONGESTION CONTROL message shall also include a
cause
No.\ 43, \fIaccess information discarded\fR .
.bp
.PP
The receipt of the receive ready indication shall be interpreted as an
indication that no more than \fIn\fR USER INFORMATION messages may be sent
before another receive ready indication is received. The value of \fIn\fR
requires further study.
.PP
Congestion control procedure itself should be regarded as local.
.RT
.sp 2P
.LP
7.1.6
\fIUnexpected USER INFORMATION messages\fR
.sp 1P
.RT
.sp 1P
.LP
7.1.6.1
\fIReceipt of USER INFORMATION messages in incompatible call\fR
\fIstates\fR
.sp 9p
.RT
.PP
Whenever a USER INFORMATION message is received from the user and it is
not allowed by an invoked service (e.g.,\ in any other state than Active
where only service\ 3 is invoked), the message will be discarded by the
network. The network will respond with a STATUS message with a cause No.\
43, \fIaccess\fR \fIinformation discarded\fR .
.RT
.sp 1P
.LP
7.1.6.2
\fIReceipt of unexpected USER INFORMATION messages\fR
.sp 9p
.RT
.PP
Whenever a USER INFORMATION message is received by the network from the
calling or called user after the network has indicated that user\(hyto\(hyuser
cannot be supported, that message shall be discarded without further
action.
.RT
.sp 2P
.LP
7.1.7
\fIRequesting user\(hyto\(hyuser signalling services 1, 2 and 3\fR
.sp 1P
.RT
.sp 1P
.LP
7.1.7.1
\fIGeneral\fR
.sp 9p
.RT
.PP
This section describes procedures for requesting services 1, 2 and 3 in
the same SETUP message. These services are described in \(sc\(sc\ 7.1.3,
7.1.4
and\ 7.1.5, respectively.
.PP
\fINote\fR \ \(em\ User\(hyto\(hyuser service 1 implicit request/acceptance
follows
\(sc\ 7.1.3.2 procedures. Only explicit service\ 1 requests may follow
the procedure in this section.
.RT
.sp 1P
.LP
7.1.7.2
\fICall establishment\fR
.sp 9p
.RT
.PP
Procedures for call establishment are described in \(sc\(sc 7.1.3.3,
7.1.4.2, and 7.1.5.2 with the following modifications. On call request, the
SETUP message sent by the calling user will contain independent service\
1, 2, 3 requests.
.PP
The SETUP sent by the network at the called sides will also contain
the same independent service requests. If the called user can support the
indicated services, then specific services acceptances may all be indicated
in the ALERTING message. Alternatively, the user may accept services\ 1
and\ 2 in
the ALERTING message, as defined in \(sc\(sc\ 7.1.3.3 and 7.1.4.2, and
service\ 3 in
the CONNECT message, as defined in \(sc\ 7.1.5.2.
.RT
.sp 1P
.LP
7.1.7.3
\fIService rejection\fR
.sp 9p
.RT
.PP
If the called user or network does not understand any of the
services requested, then the ALERTING and CONNECT messages returned to the
calling user will not include either a service acceptance or rejection. This
type of response will be taken as an implicit rejection of all services.
If the called user or network does not understand a specific service request,
that
specific service is implicitly rejected following the procedures defined in
\(sc\(sc\ 7.1.3.6, 7.1.4.3 or\ 7.1.5.3. Alternatively, if the network or
called user
cannot support one or more services requested, and the service requests were
indicated as preferred, the specific service rejection may be included
in the ALERTING messages. The services may also be rejected following the
procedures in \(sc\(sc\ 7.1.3.6, 7.1.4.3 or\ 7.1.5.3.
.PP
If the called user does not include a service 1, 2 or 3 acceptance or rejection
in the ALERTING and/or CONNECT message, the network shall return a
service\ 1, 2 or\ 3 rejection in the ALERTING and/or CONNECT message sent
to the calling user.
.PP
When interworking with a non\(hyISDN network occurs, a PROGRESS or an
ALERTING message with the Progress indicator information element indicating
No.\ 1, \fIcall is not end\(hyto\(hyend ISDN; further call progress information
may\fR
\fIbe available in\(hyband\fR , is sent to the calling user to indicate
that the
service cannot be guaranteed.
.bp
.PP
If any or all of the services requested is indicated as required, then
the network or called user that cannot support or provide the request will
send a RELEASE COMPLETE with cause No.\ 50, \fIrequested facility not subscribed\fR
,
or cause No.\ 69, \fIrequested facility not implemented\fR , and the service
rejection associated with that service.
.RT
.sp 1P
.LP
7.1.7.4
\fITransfer of USER INFORMATION messages\fR
.sp 9p
.RT
.PP
The transfer of USER INFORMATION messages is defined in \(sc\(sc 7.1.4.4
and 7.1.5.6.
.RT
.sp 1P
.LP
7.1.8
\fISummary of actions to be taken by the called side and subsequent\fR
\fInetwork action\fR
.sp 9p
.RT
.PP
Actions to be taken by the called side and the subsequent network actions
are summarized in Table\ 7\(hy1/Q.931.
.RT
.ce
\fBH.T. [T174.931]\fR
.ce
TABLE\ 7\(hy1/Q.931
.ce
\fBActions to be taken at the called side\fR
.ce
(Note 1)
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(12p) | cw(42p) | cw(48p) | cw(66p) | cw(60p) .
Case Called user's capability Requested service (Note 2) Called user action {
Calling user network interface action
}
_
.T&
cw(12p) | lw(42p) | lw(48p) | lw(66p) | lw(60p) .
1 {
Can analyze the service and accepts the service
} {
Services 1, 2, 3 preferred or required
} {
Return appropriate ACK indication by the response message
} {
Pass ACK to the calling user in normal call control messages
}
_
.T&
cw(12p) | lw(42p) | lw(48p) | lw(66p) | lw(60p) , ^ | ^ | l | l | l
^ | ^ | l | l | l.
2 {
Can analyze the service but does not accept the service
} Services 1, 2, 3 required {
Clears the call with appropriate message and cause
} {
Pass same cause to the calling user in the normal call
control clearing message
}
{
Service 1 (explicit invocation), 2, 3 preferred
} {
Return appropriate NACK indication in the response message.
The call is not cleared
} {
Pass NACK to the calling user in normal call control messages. The
call is not cleared
} {
Service 1 (implicit invocation) preferred
} {
Ignore the request or return appropriate NACK indication by
the response message, the call is not cleared
} Pass NACK to the calling user
_
.T&
cw(12p) | lw(42p) | lw(48p) | lw(66p) | lw(60p) , ^ | ^ | l | l | l
^ | ^ | l | l | l.
3 {
Cannot analyze the service request
} Services 1, 2, 3 required {
Treats as an unrecognized optional information element
} {
Clears the call with appropriate message and cause
}
Services 1, 2, 3 preferred {
Treats as an unrecognized optional information element
} {
Passes back the implicit user responses to the calling node
(Note\ 3)
}
.TE
.LP
\fINote\ 1\fR
\ \(em\ This Table covers the point\(hyto\(hypoint case. In the
point\(hyto\(hymultipoint case, it is applied only if no contention to a
broadcast SETUP EXISTS.
.LP
\fINote\ 2\fR
\ \(em\ When an implicit user\(hyto\(hyuser signalling invocation is received
for service\ 1 (which means that the user\(hyto\(hyuser information element is
included in the SETUP but the explicit invocation is not), the request is
regarded as preferred.
.LP
\fINote\ 3\fR
\ \(em\ When no indication of acceptance or rejection of requested service is received from the called user, then it is regarded an an implicit service
rejection. Therefore, in service\ 1 the user\(hyuser information element carried by originating SETUP message is not guaranteed an acknowledgement. The action
to be taken in this case is up to the calling user.
.nr PS 9
.RT
.ad r
\fBTable 7\(hy1/Q.931 [T174.931], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 2P
.LP
7.2
\fIProcedures for user\(hyto\(hyuser signalling not associated with\fR
\fIcircuit\(hyswitched calls\fR
.sp 1P
.RT
.sp 1P
.LP
7.2.1
\fIGeneral characteristics\fR
.sp 9p
.RT
.PP
This feature allows the users to communicate by means of
user\(hyto\(hyuser signalling without setting up a circuit\(hyswitched
connection. A
temporary signalling connection is established and cleared in a manner
similar to the control of a circuit\(hyswitched connection.
.RT
.sp 1P
.LP
7.2.2
\fICall establishment\fR
.sp 9p
.RT
.PP
Procedures for call establishment are as described in
\(sc\(sc 5.1 and 5.2 with the following modifications.
.PP
On call request, the calling user sends a SETUP message identifying, within
the Bearer capability and Channel identification information elements,
a temporary signalling connection to be established on SAPI\ =\ 0. The
SETUP
message is encoded to indicate:
.RT
.LP
i)
Bearer capability information element:
.LP
\(em
Unrestricted digital information in the information
transfer capability field;
.LP
\(em
Packet mode in the transfer mode field;
.LP
\(em
User information layer 2 protocol is
Recommendation\ Q.921 and user information layer\ 3 protocol
is Recommendation\ Q.931 in the layer and protocol
identification field.
.LP
ii)
Channel identification information element:
.LP
\(em
Exclusive in the preferred/exclusive field;
.LP
\(em
D\(hychannel in the D\(hychannel indicator field;
.LP
\(em
No channel in the channel selection field.
.PP
If the network determines that the requested temporary signalling connection
service is not authorized or is not available, the network shall
initiate call clearing in accordance with \(sc\ 5.3.2 | ) or \(sc\ 5.3.2 | )
with one of the following causes:
.LP
a)
No. 57 \fIbearer capability not authorized\fR ;
.LP
b)
No. 58 \fIbearer capability not presently available\fR ;
.LP
c)
No. 63 \fIservice or option not available, unspecified\fR ; or
.LP
d)
No. 65 \fIbearer service not implemented\fR .
.PP
The called user accepts the temporary signalling connection
request by sending a CONNECT message towards the calling user. After the
called user has received a CONNECT ACKNOWLEDGE message, it may begin sending
USER
INFORMATION messages. Once the calling user receives a CONNECT message,
it can begin sending USER INFORMATION messages.
.sp 1P
.LP
7.2.3
\fITransfer of\fR
\fIUSER INFORMATION messages\fR
.sp 9p
.RT
.PP
Once a temporary signalling connection is established, both users can transfer
information between themselves by transferring USER INFORMATION
messages across the user\(hynetwork interface. The network provides for the
transfer of such messages from the called to the calling side and vice
versa.
.PP
The USER INFORMATION message includes the Call reference, the
Protocol discriminator, and the User\(hyto\(hyuser information elements
as defined in \(sc\ 3.3.13. The More data information element may also
be sent by the source user to indicate to the remote user that another
USER INFORMATION message will
follow, containing information belonging to the same block. The use of
the More data information element is not supervised by the network.
.RT
.sp 1P
.LP
7.2.4
\fICongestion control of USER INFORMATION messages\fR
.sp 9p
.RT
.PP
Congestion control procedures are the same as those described in
\(sc\ 7.1.5.7.
.RT
.sp 1P
.LP
7.2.5
\fICall clearing\fR
.sp 9p
.RT
.PP
The clearing of an established temporary signalling connection can be initiated
by the user or network by sending a RELEASE message towards the
far end user. The clearing procedure followed and the timers involved are
the same as those for clearing a circuit\(hyswitched connection as described
in
\(sc\(sc\ 5.3.3 and\ 5.3.4.
.bp
.RT
.sp 2P
.LP
\fB8\fR \fBApplication of circuit\(hyswitched supplementary services to\fR
\fBterminals using stimulus procedures\fR
.sp 1P
.RT
.PP
This section describes how stimulus procedures may be used by an
ISDN terminal to invoke supplementary services.
.PP
Signalling messages sent by terminals using stimulus procedures to
invoke network supplementary services are usually generated as a direct
result of actions by the terminal user (e.g.\ feature key activation) and
in general do little more than describe the event which has taken place
at the man\(hymachine
interface (MMI). For the establishment of supplementary services, such
stimulus operations at the MMI will normally be conveyed in the keypad
or feature
activation information element within, for example, the INFORMATION message.
The meaning of the keypad or feature activation information may be customer
specific. Similarly, signalling messages sent by the network to terminals
using stimulus procedures may contain explicit instructions regarding the
operations to be performed by the terminals (e.g.\ feature indication, start
alerting,\ etc.)
.PP
Terminals using stimulus procedures are not expected to maintain a
record of the states of that service since they have a master\(hyslave
relationship with the network. Such terminals may also support only a
compatible subset of the call states defined in \(sc\ 2.1.1 and may only report
that compatible subset in the call state information element as described in
the
procedures of \(sc\ 5. At a minimum, the user shall be able to report the call
state when the call is active.
.RT
.sp 2P
.LP
\fB9\fR \fBList of system parameters\fR
.sp 1P
.RT
.PP
The description of timers in the following tables should be
considered a brief summary. The precise details are found in \(sc\(sc\
5 and\ 6, which should be considered the definitive descriptions.
.RT
.sp 1P
.LP
9.1
\fITimers\fR \fIin the network side\fR
.sp 9p
.RT
.PP
The timers specified in Table 9\(hy1/Q.931 are maintained in the
network side of the interface.
.RT
.sp 1P
.LP
9.2
\fITimers in the user side\fR
.sp 9p
.RT
.PP
The timers specified in Table\ 9\(hy2/Q.931 are maintained in the user
side of the interface. Timers\ T305, T308 and T313 are mandatory for all
T314 4 s Receiving segmented message Message segment received Last message segment received Discard message Timer is not restarted Mandatory see Annex K
T314 4 s Receiving segmented message Message segment received Last message segment received Discard message Timer is not restarted Mandatory; see Annex L
